Maintaining consistency of device driver settings

ABSTRACT

User input to a device driver to affect device driver settings is handled by a method according to various aspects of the present invention. The device driver has settings which include a plurality of values. The method includes the steps of (a) in response to user input, replacing the value of a setting with a new value; and then (b) reviewing all settings for consistency. During the review, additional replacements may be dictated according to rules (i.e., conditional procedures) which may have been received from a file into the device driver. Each rule accounts for one type of interaction. For example, when a user changes the media from letter paper to envelope using a printer driver user interface, the user interface is updated to show that two-sided printing and stapling settings are now off and not available. By allowing inconsistent settings to exist and then be corrected, user interface programming source code is made more manageable.

FIELD OF THE INVENTION

[0001] Embodiments of the present invention relate to a user interfaceprovided by a device driver and to data structures and methods ofmaintaining consistency of settings accessible via such a userinterface.

BACKGROUND

[0002] Computer systems output data to a variety of output devices, suchas, printers, plotters, and video displays. These systems also acceptinput data from a variety of input devices, such as, scanners, networkdevices, and speech recognition interfaces. Each device typically has amanufacturer-defined device-specific protocol for communicating with thedevice. A computer system, under the control of an operating system,uses the protocol to communicate with each device. An operating systemmust, therefore, be programmed to cooperate with the protocol of eachdevice to which it is connected. It would be impractical for anoperating system developer to provide an interface to every availableperipheral device. Moreover, frequent revisions to an operating systemto permit it to cooperate with new peripheral devices may addunnecessary cost to the provision and support of an operating system onmultiple computers. To overcome these difficulties, operating systemsinterface with peripheral devices indirectly through device drivers. Theoperating system developer defines a device driver interface between theoperating system and the device driver. Each manufacturer of a devicethen provides a device driver, which implements the device driverinterface and further, implements the protocol for communicating withthe peripheral device. The operating system or application program loadsthe device driver and invokes the functions of the device driverinterface to communicate with the device.

[0003] An operating system also provides support for applicationprograms. To this end, the operating system developer defines anapplication program interface over which an application program maycommunicate to obtain the services of peripheral devices. Such anapplication program interface is commonly called a Graphics DeviceInterface (GDI) and is typically part of the operating system. The GDIeffects the output of data by invoking functions implemented by thedevice driver in accordance with the device driver interface. The GDIand device drivers insulate the application program from the differentcharacteristics of peripheral devices. The GDI provides a variety offunctions for accessing devices in a device-independent manner. Anexample of a GDI is described in Programming Windows 3.1 by CharlesPetzold, published by Microsoft Press, incorporated herein by reference.The GDI also specifies behavior of each function that a device drivermust implement. For example, one GDI for a printer specifies sixcategories of functions implemented by a device driver: (1)initialization, (2) information, (3) output, (4) attribute, (5) mode,and (6) escape as described in Table 1. TABLE 1 Function Description (1)Initialization Control Performs device-dependent operations such asstarting an output job, aborting an output job, and processing a newband of bitmap data; Disable Deallocates memory used by the devicedrivers data structures and unloads the device driver from memory;Enable Allocates and initializes memory for a data structure containingdevice dependent and device state information; WEP Signals the devicedriver that the operating system is shutting down; (2) InformationColorInfo Translates physical colors to logical colors and vice versa;EnumDFonts Enumerates the fonts available on the device; EnumObjEnumerates the pens and brushes that are available on the device;DevGetCharWidth Returns width values for characters in a specifiedprinter font; (3) Output DevBitBlt Sets pixels on the output device;DevExtTextOut Renders text on the output device; Output Renders s shapeon the output device; Pixel Sets a single pixel on the output device;ScanLR Sets pixels in a single row of the output device; StretchBltRenders scaled bitmaps on the output device; (4) AttributesRealizeObject Converts a logical pen, brush, font, etc. data structureto a physical pen, brush, font, etc. data structure; (5) ModesDeviceMode Displays a dialog box that allows a user to select deviceoptions, such as, paper size, paper orientation and output quality; (6)Escape QueryEscSupport Specifies whether the output device supports aspecified escape sequence; SetAbortDoc Invokes the abort procedure ofany application program; StartDoc Signals the beginning of an outputjob; NextBand Outputs a band of bitmap data; EndDoc Signals the end ofan output job; AbortDoc Signals the abnormal termination of an outputjob;

[0004] As an example of the operation of the GDI described above, anapplication program outputs data to a particular device by firstrequesting the GDI to create a device context. The device contextidentifies the particular peripheral device and contains the currentstate of the peripheral device. For example, the device context maycontain the current font and brush information. The GDI provides theapplication program with a handle to the created device context. Theapplication program passes the handle to the device context whenever theapplication program outputs data to the particular device. The GDIfunctions use the passed handle to access the device context.

[0005] Each of the functions provided by a device driver may be uniquelyprogrammed by the manufacturer of the peripheral device. This approachleads to several areas of difficulty which add to the cost of providingperipheral devices for mass marketing distribution. For example, when amanufacturer provides several lines of peripheral devices, it isdesirable to provide device drivers implemented from reusable softwarecomponents. In this approach, each new peripheral can be supported witha device driver having consistent behaviors shared with device driversbuilt for prior peripheral device products. In addition, it is desirableto design device drivers that are portable (i.e., common code reused fordifferent operating systems), flexible (i.e., new features may be addedwith minimal redevelopment and testing), and consistent (i.e., thestructural organization of the device driver software is similar amongdevice drivers for different products and/or different product lines).

[0006] A device driver may provide a user interface for permitting theuser of an application program to modify selected attributes of thedevice context. The operating system cooperates with the device driverto provide the user interface. In a conventional user interface, dialogboxes are shown on the screen with controls that respond to user inputfor the specification of new values for attributes. Because the dialogbox provides the user with the flexibility of modifying attributes in anad hoc manner, conventional device drivers assure that user input willnot result in an inconsistent group of attributes.

[0007] An attribute is referred to herein as a device setting. Aplurality of attributes may be collectively referred to as a devicesetting or as a plurality of device settings. Therefore, a devicesetting may include one or more attributes. Each attribute may bereferred to as a parameter. Each attribute has an identity and one ormore values.

[0008] Typically, consistency checks are made prior to modifying thevalue of a device setting. That portion of the device driver programresponsible for accepting a modified device setting for one of thecontrols of the dialog necessarily is programmed with knowledge of thebehavior of one or more other controls. This interaction betweencontrols complicates software development of the device driver userinterface. Further, by accounting for consistency checking in theprogramming of each control, the resulting device driver user interfaceis less amenable to reuse for the development of future device drivers.Development of device drivers using this approach, therefore, cannotobtain the desirable features discussed above.

[0009] In view of the problems described above and related problems thatconsequently become apparent in the art of device driver development,the need remains for methods of responding to user input provided to adevice driver and methods for maintaining the consistency of devicesettings.

SUMMARY

[0010] A memory device in one embodiment of the present invention hasindicia of a method for responding to user input provided to a devicedriver. The device driver has settings. Each setting has a respectivevalue. The method includes the steps of (a) in response to user input,establishing, for a first setting having a first value, a second valuefor the first setting, the second value replacing the first value, thesecond value being a member of the plurality of values; and (b) afterthe step of establishing, reviewing for consistency the plurality ofvalues.

[0011] By establishing a possibly inconsistent plurality of values andthen reviewing for consistency, various consistency checks may be mademore efficiently and the programming source code for implementing themethod may be written and maintained in a manner less prone to redundantlogic.

[0012] A memory device in another embodiment of the present inventionhas indicia of a method for responding to user input provided to adevice driver. The device driver has settings. Each setting has arespective value. The method includes the steps of: (a) in response touser input, establishing, for a first setting having a first value, asecond value for the first setting, the second value replacing the firstvalue, the second value being a member of the plurality of values; and(b) performing a review after the step of establishing. The reviewincludes the steps of (b1) storing in a first list an indicia of thefirst setting; and (b2) executing in turn each procedure of a pluralityof procedures, each procedure possibly affecting a second list; and (b3)in response to determining that the second list is not empty, performingthe following steps: (i) replacing the contents of the first list withthe contents of the second list; and (ii) repeating the review. Eachprocedure of the plurality of procedures includes indicia of a settingto be tested. Each procedure performs the following steps: (a)proceeding with performance of the respective procedure upon successfulcomparison of the contents of the first list and the respective indiciaof a setting to be tested; (b) establishing, for a respective secondsetting having a third value, a fourth value for the second setting, thefourth value replacing the third value, the fourth value being a memberof the plurality of values; and (c) storing in a second list an indiciaof the respective second setting.

[0013] By using two lists, all procedures review the same context forinconsistency checking, namely the context provided by the first list.Making reference to the first list for context minimizes any consequenceof interaction between procedures, simplifying device driver userinterface development.

[0014] A memory device in a third embodiment of the present inventionincludes indicia of a method for maintaining consistency of a pluralityof settings for a peripheral device. The method includes the steps of(a) modifying at least one setting of the plurality of settings inresponse to user input; (b) after the step of modifying, validating theplurality of settings by performing a plurality of checks, where eachcheck includes conditionally further modifying the plurality of settingsin response to determining that an inconsistency is present among theplurality of settings; and (c) repeating the step of validating, inresponse to determining that any check determined that an inconsistencyindeed was present.

DESCRIPTION OF THE DRAWINGS

[0015]FIG. 1 is a functional block diagram of a computer systemaccording to various aspects of the present invention;

[0016]FIG. 2 is a data flow diagram of operation of the device driver inthe computer system of FIG. 1; and

[0017]FIGS. 3 through 5 constitute a flow chart of a method performed bythe device driver of FIG. 2.

DETAILED DESCRIPTION

[0018] The present invention provides a method executed by a computerfor maintaining consistency of a plurality of settings for a peripheraldevice. For example, a computer system, according to various aspects ofthe present invention, includes a computer, a monitor, a user inputdevice, and one or more peripheral devices. Inasmuch as sophisticatedperipheral devices conventionally include a computer, a front paneldisplay, and touch panel switches as a user input device, the operationof the method of the present invention may be performed entirely withina peripheral device. On the other hand, computers and peripheralsinterconnected by conventional data communications may also serve as aplatform for performance of a method according to various aspects of thepresent invention. The term computer, therefore, includes a variety ofdata processing circuits and systems ranging from a microcontrollerserving a process control function, a laptop or desktop computer servinga personal information organization function, or an assembly of clientand server equipment interconnected by a network for providing supportfor a wide range of conventional peripheral devices. Of course, acomputer conventionally includes one or more processors in cooperationwith one or more memory devices. A memory device includes anysemiconductor circuit, magnetic, or optical data storage device, whichmay be removable, nonremovable, read only, or read/write. Such a memorydevice includes, according to various aspects of the present invention,indicia of instructions or statements which are executable orinterpretable by one or more of the processors.

[0019] For example, various methods of the present invention will bedescribed with reference to FIGS. 1 through 5 depicting a simplifiedpersonal computer system. A computer system, according to variousaspects of the present invention, provides consistent device settings inresponse to modification of device settings by a user of the computersystem. Consistency is obtained by a method for responding to user inputprovided to a device driver. Such a method is performed, for example, bya device driver that cooperates with an operating system and aperipheral device. Computer system 100 of FIG. 1, includes computer 102,monitor 104, keyboard/mouse 106, and peripheral device 108. Computer 102includes a conventional computer as discussed above, which in operationexecutes the instructions of an operating system 110, one or moreapplication programs 114, 116, and a device driver 112 for the purposeof coordinating use of the peripheral device 108 in accomplishing thepurposes of one or more application programs.

[0020] Monitor 104 may be any conventional computer monitor. As shown,monitor 104 presents a graphical user interface (GUI) in cooperationwith operating system 110.

[0021] To receive user input in response to information displayed onmonitor 104, computer system 100 includes a conventional keyboard, aconventional pointing device, or a combination of other conventionalinput devices. A user of computer system 100 operates input devices 106to make selections and/or dictate values in cooperation with theoperating system's GUI.

[0022] Peripheral device 108 may include any conventional peripheraldevice including input devices, output devices, and devices for anycombination of input and output. Input devices include keyboards,pointing devices, document scanners, audio capturing devices, videocapturing devices, and conventional instrumentation. Output devicesinclude monitors, printers, facsimile, copiers, image recordingapparatus, audio reproduction devices, and conventional process controlapparatus. Input/output devices may include conventional audio, video,and data communications devices, network interface equipment, telephoneequipment, and information appliances.

[0023] As discussed above, each peripheral device may cooperate with acomputer according to a unique electrical and communications protocol.Because peripheral devices are manufactured to accommodate a widevariety of differing computer system environments, and becauseperipheral devices are manufactured with a wide variety of capabilities,the conventional peripheral device necessarily includes an interface forthe specification of a wide number of device-specific attributes. Thetypes, functions, and names of attributes (and values for the sameattribute) may vary between peripheral devices, between installations ofthe same peripheral device, and between applications of the peripheraldevice for the performance of functions of one or more applicationprograms. A device setting includes one or more values for attributesand further may include attribute identifiers (e.g., name strings). Forexample, device settings may be different for each print job directed toa printer. Device settings are managed by a program conventionallycalled a device driver.

[0024] Operating System 110 may include any program for managing theexecution of one or more application programs. For example, OperatingSystem 110 may include the WindowsNT Operating System marketed byMicrosoft Corporation (WINDOW NT is a trademark of MicrosoftCorporation). Operating system 110 provides a graphical user interfaceand one or more interfaces to device drivers. For example, the interfacebetween operating system 110 and device driver 112 with respect toperipheral device 108 as a conventional laser printer, includes agraphics device interface, as described above. Operating system 110 alsoprovides application program interfaces for the cooperation ofapplication programs 114, 116 with operating system 110 and cooperationof applications programs 114, 116 and device driver 112. For simplicityin describing the methods according to various aspects of the presentinvention, all communication involving device driver 112 and otherprocesses of computer 102 is summarily referred to as being supported bya device driver interface.

[0025] A graphical user interface provides information to the user bypresenting message boxes and/or dialog boxes. A dialog box, as shown inFIG. 1, may include a title bar 119 and a body 120. Body 120 may includevarious controls including tabbed pages 121, list box 122, and check box124. In a conventional manner, the user of computer system 100 maydirect a pointing device 106 with visual feedback provided by a mousepointer 126 that appears on the monitor 104. By directing the mousepointer 126 to a portion of list box 122, the user may select one ormore items from list box 122. In the example shown, operating system 110has provided a dialog box entitled “Device Properties” for a printer, asperipheral device 108. One or more of the tabbed pages 121 may include aso-called properties page which provides a user interface for modifyingprinter device settings. In the example shown, property page 121describes current device settings for media type and duplex operations.As shown, media type is currently “envelope” and the duplexing operationhas been selected as shown by the filled checkbox 124. Although it isconventional to apply duplex printing to media of letter or legal size,one or more device settings calling for duplex operation on an envelopeare herein considered inconsistent. One or more device settings may beconsidered inconsistent because (a) operation according to the devicesetting(s) exceeds the capability of peripheral device 108 or (b)operation according to the device setting(s) exceeds the specificationfor the system design and so is not to be supported. Peripheral device108 is not equipped to provide a duplex operation on envelopes. Ofcourse, other peripheral devices, as well as other printers, may haveother combinations of inconsistent attribute values. In this example,the media type attribute and the duplex operation attribute areillustrated as inconsistent for the purpose of describing a method formaintaining consistency, according to various aspects of the presentinvention.

[0026] For the support of user-modified device settings, device driver112 includes several processes as illustrated, for example, in FIG. 2.Device driver 112 includes initialization process 214, user interfaceprocess 222, validation process 224, job preparation process 242, anddevice interface process 244. Device driver 112 supports the capabilityof reading device specific information from device models file 202. Forexample, initialization process 214 may read device models file 202 andstore values of device settings in driver's settings 216. Thisinitialization of driver's settings 216 may be accomplished upon theinitial installation of peripheral device 108, or upon a configurationchange in peripheral device 108 at any time. Such a configuration changemay include the installation of additional mechanical or electricalapparatus, as desired. Installation of a peripheral device may be actualor virtual. Actual installation includes the physical and/or logicalconnection of actual peripheral device 108 to computer 102. Virtualinstallation may include, for example, configuring device driver 112 toprovide data or to receive data via a network or mass storage device forthe purpose of a store-and-forward operation without connection of anactual peripheral device. Virtual installation provides the capabilityof supporting functions of application program 114 or 116 in anenvironment where peripheral device 108 is unavailable.

[0027] When properly configured, device driver 112 provides data frominput peripheral devices through device interface process 244 and jobpreparation process 242 to supply data and settings to applicationprograms 114, 116. In such an operation, device interface process 244handles device I/O according to the protocol unique to peripheral device108, as discussed above. Also, job preparation process 242 receivesinformation from device interface process 244, for example, text for ascanned page and provides that information to the application programrequesting cooperation with peripheral device 108. Job preparationprocess 242 may provide device settings as stored by device driver 112or as provided by peripheral device 108 in connection with an I/O job.

[0028] For supporting an output peripheral device, job preparationprocess 242 receives information from application programs 114, 116 andprovides that information as an I/O job to device interface process 244.Device interface process 244 cooperates with peripheral device 108according to the protocol discussed above to transfer data to the outputdevice.

[0029] Device driver 112 includes any program supporting input, output,or input/output peripheral devices as described above. In addition,device driver 112 permits modification of device settings in accordancewith one or more client user interface sessions. Device driver 112 maysupport interaction with operating system 110, application program 114,and application program 116. One or more client user interface sessionsmay be sequentially or simultaneously supported. For example, clientuser interface session 220 includes a unique instantiation of userinterface process 222, validation process 224, undo list 226, reviewlist 227, and client's settings 228.

[0030] Initialization of all client user interface sessions may beaccomplished by initialization process 214. Initialization process 214establishes driver's settings 216 which may be read for system leveldefault settings. Driver settings 216 may be stored and recalled from afile (e.g., an .INI file) and/or from the registry maintained by theoperating system. Any client user interface session may perform anotherinitialization process to establish a starting point for further userinteractive review and/or modification of device settings.Alternatively, device driver 112 may, at any time, initialize aparticular client user interface session according to controls,features, and rules available to the device driver through operatingsystem 110.

[0031] Client user Interface 220 may read controls file 204, featuresfile 206 and rules file 208 in order to initialize user interfaceprocess 222 and validation process 224. Controls file 204 may includedata and/or program instructions for completely or partially describingcontrols, dialog boxes, and/or message boxes to be used by userinterface process 222. Information from controls file 204 is sufficientfor user interface process 222 in defining all operations in cooperationwith the graphical user interface of operating system 110. By readingcontrols file 204, a particular client user interface session 220 maypresent a different layout, logic, and organization supportingmodification of device settings.

[0032] User interface process 222 may also read features file 206.Features file 206 may include data and/or program instructions thatcompletely or partially describe one or more device settings. Adescription of a device setting may include, an attribute identifier, arange of values permitted for the attribute, and/or a list of permittedor restricted values. In operation, for example, features correspondingto optional equipment may be read by user interface process 222 inconjunction with the installation of corresponding equipment inperipheral device 108.

[0033] Validation process 224, as will be discussed in detail below,performs one or more consistency checks for each one or group of devicesettings. Although all consistency checks may be organized as a singleprocess (i.e., a single rule), in a preferred configuration, validationprocess 224 performs a set of processes, each process being limited inscope to cover possible inconsistencies among a subset of devicesettings.

[0034] Rules file 208 may include a complete or partial set of processesto be applied in connection with one or more device settings. Rules file208 may include rules affecting device settings for one or moreperipheral devices when, for example, device driver 112 supports morethan one (or more than one type) of peripheral device.

[0035] Information in device models file 202, controls file 204,features file 206, and rules file 208 may be stored in any conventionalformat in one or more physical files. Device models file may includeinformation of the type described in U.S. Pat. No. 5, 604,843 to Shawentitled “Method and system for Interfacing with a Computer OutputDevice,” incorporated herein by reference. Alternatively, multipledevices may be described in one device models file. Informationdescribed above with reference to files 202 through 208 may conform to aformat of the type resulting from a conventional object serializationprocess for moving the state of an object from memory (e.g., RAM)accessed for instruction execution to other memory (e.g., disk). Storingand loading rules as serialized objects facilitates preparing,distributing, modifying, updating, loading, and integrating rules for avalidation process.

[0036] Operation of client user interface 220 may be better understoodin light of an example wherein it is assumed that peripheral device 108is a conventional laser printer and application programs 114 and 116 areconventional word processing programs. In this example, device driver112 may provide access to device settings in at least one of three ways.First, device settings may be stored in the context of computer system100 for use by all users of the same peripheral device. Access to suchsystem level device settings is provided to operating system 110 bydevice driver 112, for example, by means of dialog boxes appropriate forsystem administration. Second, device settings may be accessed on a userand/or application program basis, for example, so that a user may becomeaccustomed to specific peripheral device operation in cooperation withprograms selected by the same user. These user and/or applicationprogram specific device settings may be stored in the user's profileand/or an application program profile. When stored in an applicationprogram profile, all users of the application program may have use ofthe peripheral device from similar device settings. Third, devicesettings may be stored with (or in association with) an I/O job that isassociated with the particular peripheral device. In the latter case,for example, printer device settings may be stored with a document to beprinted. In each of these three modes of accessing and storing devicesettings, device settings may include all or a selected portion of thedevice settings available in connection with a particular peripheraldevice.

[0037] When application program 114 requests access to device settingsfor a printer (e.g., to print a word processing document), device driver112 activates a client user interface 220 and a user interface process222. User interface process 222 may receive default device settings fromseveral sources. For example, device settings may be recalled fromdriver settings 216 to give effect to stored system level devicesettings. When appropriate, user or application program specific devicesettings may be recalled from client's settings 228. And, devicesettings may be provided to device driver 112 from the applicationprogram in connection with a particular I/O job. Regardless of themethod by which user interface process 222 obtains current and/ordefault device settings, user interface process 222 prepares a dialogbox with appropriate controls and appropriate initial values of theattributes described by the dialog box and then presents the dialog boxvia the GUI to the user. Upon receipt of user input, user interfaceprocess 222 prepares suggested device settings and provides thesuggested device settings to validation process 224. In addition toproviding suggested device settings, user interface process 222 may postattribute identifiers and values on undo list 226 and may post attributeidentifiers on review list 227, for purposes described in greater detailbelow.

[0038] Validation process 224, upon receipt of suggested devicesettings, reviews the suggested device settings for consistency amongthe suggested device settings themselves and/or consistency among alldevice settings including the suggested device settings. If aninconsistency is determined to exist, validation process 224 may revisethe originally suggested device settings or make a copy of theoriginally suggested device settings and revise the copy. In eithercase, validation process provides such revised device settings to one ofthree destinations. Revised device settings may be provided directly touser interface process 222 in response to the earlier provision ofsuggested device settings. Revised device settings may also be stored inclient's settings 228 as newly established default settings. Or, reviseddevice settings may be provided to the operating system or applicationprogram in response to device driver 112 being called by eitheroperating system 110 or application program 114. In each case, reviseddevice settings are sure to be internally consistent and/or consistentwithin all device settings.

[0039] Consistency of device settings is maintained, in accordance withvarious aspects of the present invention, by performing a methodpreferably performed by device driver 112, particularly client userinterface 220. A method of the present invention includes any methodthat establishes suggested device settings prior to reviewing devicesettings for consistency. Such a method may be implemented according toany programming language and program development methodology. Forexample, such a method may be implemented using object-orientedprogramming techniques, procedural programming techniques, or acombination of object-oriented and procedural techniques. For simplicityof explanation, a procedural description of such a method is describedin the flow charts presented in FIGS. 3 through 5.

[0040] At step 302 of FIG. 3, a dialog box is presented to the user. Ina graphical user interface (GUI), the presentation of a dialog boxbegins a user input session during which the user may activate variouscontrols presented graphically in the dialog box. These controls includeany conventional feature of a dialog box supported by the operatingsystem including, for example, a command button, a text box, a list box(possibly with horizontal and vertical scroll bars), a drop down listbox, an option button, a check box, a spin-edit box, or a combo-box.Upon activation of a control, the operating system passes a message tothe device driver. For example, because the dialog box in step 302 waspresented by device driver 112, operating system 110 will provide a userinput event message to device driver 112 on the completion of any userinput event. The completion of a user input event may be the completionof an entry in a text box, the completion of selection of one or moreitems from a list box, the activation of an exclusive option button, orthe activation of one or more non-exclusive check boxes. Command buttonsinclude (a) the conventional “OK”, “Cancel”, and “Help”; (b) buttonsthat give rise to one or more additional dialog boxes, for example,“Settings”, “Set-up”, or “Options”; and (c) buttons (tabs that mayappear in a tab-organized dialog box) that activate another propertypage. If the user input event includes text (as in a text box) or anumeric entry (as in a spin-edit box), the text string or numeric valuemay accompany the user input event message.

[0041] At step 304, device driver 112 receives notice of a user inputevent. Such a notice may include information from which device driver112 may determine the type of event that occurred. Such information isdefined by the device driver interface. Accordingly, at step 306, devicedriver 112 is able to determine whether the “Cancel” command button wasactivated or at step 310 whether the “OK” command button was activated.

[0042] At step 306, device driver 112 determines that the “Cancel”command button was activated, device driver 112 takes no further actionand exits at step 312 control returns to the operating system or to theapplication program, whichever initially took action requiring thedevice driver's response.

[0043] At step 310, device driver 112 determines whether the “OK”command button was activated. If so, the user has indicated that thedevice settings shown in the dialog box presented in step 302, or asdiscussed in detail below, are acceptable.

[0044] At step 308, device driver 112 communicates the device settingsto operating system 110 or to the application program that called devicedriver 112. Settings may be communicated by passing a pointer to adevice settings structure in a manner as described above with respect toa device context. Note that such a device settings structure, byoperation method 300, is assured to be internally consistent.

[0045] At step 311, user interface process 222 obtains information fromthe operating system that includes an identifier of the attributeaffected by the user input event and a new value for the attribute, ifany. An identifier of the attribute may include a reference to thedialog box control used to modify the attribute or a reference to a nameof the attribute. A reference in either case may include a string value,an enumerated code, a pointer, and/or a handle. Interface process 222may include a map (or mapping process) that translating the identifierprovided by the operating system to an entry point for processing theidentified attribute event. When the operating system supports handlingmultiple entries in a dialog box, the information supplied by theoperating system may include a data structure for each usermodification/selection, each data structure including an attributeidentifier and one or more values.

[0046] If neither the “Cancel” nor the “OK” command button has beenactivated, the user input event is understood to include one or moremodified or selected values for one or more attributes as indicated inthe dialog box. At step 320 device driver 211 obtains from the messageobtained at step 304 the identifier of the attribute(s) affected by theuser input event. The current value(s) for each identified attribute isthen obtained, and at step 322 is posted on undo list 226. An identifierof the attribute to which each value is associated is also posted onundo list 226.

[0047] At step 324, the name of each attribute is also posted on reviewlist 227. Undo list 226 and review list 227 may be organized in anyconventional manner, including organization as an array of structures, alinked list, or according to a combination of conventional data storagetechniques.

[0048] At step 326, user interface process 222 prepares suggested devicesettings in accordance with the attribute(s) and value(s) received atstep 304. Suggested device settings may include a data structure havingall device settings recorded therein, a pointer to such a structure, ora data structure describing the device settings only to the extentmodified by user input.

[0049] At step 340, validation process 224 receives the suggestedsettings and performs a validation process indicated as a subroutinecall, discussed below.

[0050] Upon return from all places the validate settings subroutine 340,at step 341, review list 227 is cleared. The undo list may also becleared. After clearing, the contents of the review list or undo listindicates no listed items (e.g., no attribute identifiers or values). Atstep 390, user interface process 222 updates the presented dialog box.Control then passes back to step 304 to await an additional user inputevent.

[0051] Validation process 224 performs a validate settings process, forexample as described in FIG. 4. The validation process may perform thevalidate settings subroutine 340 at any time that suggested devicesettings are available for review.

[0052] At step 342, a binary value referred to as the “inconsistencyflag” is reset. The terminology “set” and “reset” does not imply whichof the two binary values of the flag is associated with the assertedstate of the flag. In other words, if “0” is the asserted state of theflag by design choice, then resetting the flag is accomplished byassigning the value “1” to the binary flag value.

[0053] Validation may be accomplished by performing in turn each processof a predefined set of processes. The predefined set of processes may bedeveloped as a core capability of device driver 112. However, accordingto various aspects of the present invention, information for performingone or more processes (or one or more sets of processes) may be read bydevice driver 112 from rules file 208 and incorporated for reference bythe validation process 224 as discussed above. Upon entry of thevalidate settings subroutine, the set of processes sufficient tovalidate device settings has already been established. At step 344, afirst rule is selected from this set of processes. The set of processesmay be organized according to a predefined selection sequence. Forexample, rules may be ordered to be selected according to priority.Higher priority rules being selected prior to lower priority rules. Byestablishing a priority for each rule, for example, such that ruleswhich may affect multiple attribute values are considered with higherpriority than rules which affect a lesser number of attributes,validation of device settings may be accomplished more efficiently, orwith less risk of falling into an undesirable indefinite state. Anindefinite state may arise when two rules dictate different values forthe same attribute. Following selection of a first rule, control passesinto a loop which includes steps 346, 380, and 382.

[0054] At step 346, the selected rule is applied to the suggested devicesettings (or all device settings including the suggested devicesettings). Metacode descriptions of the operative portion of a fewexemplary rules are set out in Table 2. TABLE 2 Example Check MetacodeDescription Media sizes IF (settings specify duplexing) THEN allowed for IF (mediaSize is envelope, legal, A5, or custom) THEN duplexing    askuser “Keep duplex?”   IF (response is “yes”) THEN     impose secondaryeffects: mediaSize = letter   ELSE undo this user input cycle   ENDIF ENDIF ENDIF Media types IF (settings specify mediaType as transparency,fed only   glossy, label, or cardstock) THEN from MP  IF (settingsspecify mediaSource as not MP tray) THEN tray    tell user “Must Use MPtray”    impose secondary effect: mediaSource = MP tray  ENDIF ENDIFColor Enforce the following matrix: treatment treatment ICM OCSColorSmart off RGB ICM on RGB Custom off RGB Gray off Gray

[0055] Step 346 may be defined as a subroutine as illustrated forconvenience in FIG. 4. After application of the selected rule, controlpasses on return from the subroutine to step 380. At step 380, it isdetermined whether all rules in the set of processes have been applied.If not, at step 382, the next rule from the set of processes is selectedand control passes back to step 346, if all rules have been applied,control passes from step 380 to step 384.

[0056] At step 384, it is determined whether the inconsistency flag hasbeen set by operation of at least one of the rules in the set ofprocesses. If the inconsistency flag has not been set, validation ofdevice settings is complete and control passes via the return at step386 back to step 360, as described with reference to FIG. 3.

[0057] If it is determined that the inconsistency flag has been set,control passes back to step 342 to repeat the validate settingssubroutine as a whole. By repeating the validate settings subroutine asa whole, any attribute values that may have been modified during theperformance of any selected rule are also reviewed for the possibilityof an inconsistency among all device settings. As an alternative toestablishing a priority among rules, as discussed above, transfer backto step 342 may be limited to an arbitrary number of times, after whichtransfer of control passes to step 386 regardless of the state of theinconsistency flag.

[0058] Application of a selected rule is accomplished without regard tothe complexity or simplicity of the rule. For example, subroutine 346 isdescribed in an exemplary flow diagram of FIG. 5. At step 348,validation process 224 determines whether an attribute of the selectedrule appears on review list 227. For each rule, the attributes referredto and/or modified by the rule are available on a list, called a scopelist, associated with the rule. To determine whether an attribute of thescope list of the selected rule is on the review list 227, validationprocess 224 performs a conventional comparison between these two lists.If one or more attribute identifiers (e.g., name strings) appear on bothlists, then control passes to step 350. If not, control then passes tostep 370, whereupon the rule is considered to have been applied and theapply-selected-rule subroutine returns to step 380 described above withreference to FIG. 4.

[0059] At step 350, validation process 224 determines whether one ormore attribute values are to be modified in the process of applying theselected rule. Such a modification dictated by a rule is herein called asecondary effect. When determining the current value associated with anattribute, an attribute identifier (e.g., supplied or mapped frominformation received at step 311) may be passed to an object responsiblefor all attribute values. When the attribute values are organized as atree, the object searches the tree for a node having an attributeidentifier matching the attribute identifier passed. The value(s)associated with the attribute are then returned. By maintainingattributes in an object's state data without reference to memoryaddressing, settings (e.g., driver's settings, client's settings,suggested settings, and revised settings) may be stored and communicatedusing conventional object serialization techniques. By arrangingattributes in a tree, name conflicts among attributes may be avoided andmultiple devices (printer or printer accessory models) may be describedin the same tree.

[0060] At step 352, it is determined whether the modification of anattribute is needed in order to restore consistency in the suggesteddevice settings (or all device settings including the suggested devicesettings). This determination may be accomplished either (a) by allowingthe rule to impose modifications immediately and later comparing thesettings after the rule has been applied to detect if modifications infact were made; or (b) by determining that a modification of aparticular attribute is dictated by the rule prior to making themodification. The logic of step 350 is illustrated in Table 2 and inFIG. 5 according to the second approach. If no secondary effects are tobe imposed, control passes to step 370 for a return to the callingprocess as described above. If secondary effects are (or have been)imposed, control passes to step 353.

[0061] At step 353, validation process 224 determines whether it isnecessary or desirable to inform the user of a secondary effect detectedby application of the selected rule. In cases where it is not desirableto inform the user of the secondary effect, control passes to step 360.On the other hand, where it is desirable to inform the user and/orpermit the user to retract one or more of the user's input events,control passes from step 353 to step 354.

[0062] At step 354, Validation process 224 presents one or more dialogor message boxes to inform the user of the nature and possibleconsequences of this secondary effect. This presentation of informationmay be accomplished in any conventional manner. For example, aconventional message box with the “OK” command button may be used.

[0063] At step 356, Validation process 224 awaits another user inputevent. Upon obtaining a user input event in the context of the presenteddialog or message box, control passes to step 358 or step 360. Controlwill pass to step 358 if the user's response includes operation of a“Cancel” control.

[0064] At step 358, in response to user input received at box 356, oneor more user-directed modifications will be reversed. In addition,secondary effects may also be reversed. To reverse a change, referenceis made by validation process 224 to undo List 226. As discussed above,an attribute identifier and prior value may be stored on undo list 226.The contents of undo list 226 may include values for attributes whichthe user has modified, for example, as posted at step 322; or,attributes and values as posted during operation of any selected rule,for example as posted at step 360. At step 358, it is preferred toreinstate the attribute values that existed prior to receipt of the userevent indicated at step 304. Note that if the user input event at step304 has been validated by a complete operation of step 340, then thescope of the undo operation at step 358 corresponds to undoing one userinput event cycle.

[0065] Control passes from step 356 to step 360 on the determinationthat the user's response at step 356 was operation of a “Continue”control. At step 360, 362 and 364, validation process 224 performsoperations as described in step 322, 324, and 326 in an analogous mannerwith respect to the one or more attributes and values defined to bemodified in compliance with the selected rule as discussed above withreference to step 350.

[0066] At step 366, the inconsistency flag is set. Note that theinconsistency flag will not be set if (a) at step 348 no attribute onthe review list implicates application of the selected rule; (b)application of the rule would not involve modifying the value of anyattribute; or (c) the attribute modification deemed necessary by therule was not accomplished as directed by a “Cancel” operation.

[0067] In an alternate method, according to various aspects of thepresent invention, determination of an inconsistency does not involve aninconsistency flag. Instead, validation includes the following modifiedsteps.

[0068] At step 324, posting is made to a first review list. Before step340 of FIG. 3, a second review list is cleared. At step 362 of FIG. 5,attribute(s) for secondary effect(s) are posted to a second review list.And, at step 384 of FIG. 4, inconsistency is determined to exist whenthe second review list is not clear, i.e., at least one secondary effectattribute was modified. Each rule at step 348 refers only to the firstreview list. If inconsistency is determined to exist, the second reviewlist is copied (to replace) the first review list; and, the secondreview list is cleared before continuing with step 344.

[0069] The forgoing description discusses preferred embodiments of thepresent invention which may be change or modified without departing fromthe scope of the present invention as defined in the claims. While forthe sake of clarity of description, several specific embodiments of theinvention have been described, the scope of the invention is intended tobe measured by the claims as set forth below.

What is claimed is:
 1. A memory device having indicia of a method forresponding to user input provided to a device driver, the device driverhaving settings, each setting having a respective value, the methodcomprising: in response to user input, establishing, for a first settinghaving a first value, a second value for the first setting, the secondvalue replacing the first value, the second value being a member of theplurality of values; and after the step of establishing, reviewing forconsistency the plurality of values.
 2. The memory device of claim 1wherein the step of reviewing further comprises: selecting a firstprocedure from a plurality of procedures, selection being in accordancewith an indicia of the first setting; and performing the firstprocedure.
 3. The memory device of claim 2 wherein: the method furthercomprises storing, on a first list, the first value associated with anyindicia of the first setting; and the first procedure comprises:identifying a second setting having a third value that is inconsistentwith the second value; providing a message to the user, the messageidentifying the second setting; and in response to user input, and inaccordance with contents of the first list, reinstating the first valuefor the first setting.
 4. The memory device of claim 2 wherein: themethod further comprises storing in a first list an indicia of the firstsetting; and the step of selecting is performed in accordance withcontents of the first list.
 5. The memory device of claim 2 wherein: thefirst procedure comprises establishing, for a second setting having athird value, a fourth value for the second setting, the fourth valuereplacing the third value, the fourth value being a member of theplurality of values; and the step of reviewing further comprises:selecting a second procedure of the plurality of procedures, selectionbeing in accordance with an indicia of the second setting; andperforming the second procedure.
 6. The memory device of claim 5wherein: the method further comprises storing in a first list theindicia of the first setting and the indicia of the second setting; andeach step of selecting is performed in accordance with contents of thefirst list.
 7. The memory device of claim 5 wherein the first procedurefurther comprises providing a message to the user, the messageidentifying the second setting.
 8. The memory device of claim 5 whereinthe method further comprises: storing, on a first list, the first valueassociated with any indicia of the first setting; storing, on the firstlist, the second value associated with any indicia of the secondsetting; and in response to user input, and in accordance with contentsof the first list, reinstating each respective value contained in thefirst list for each respective setting identified by associated indiciaof a respective setting.
 9. The memory device of claim 2 wherein themethod further comprises reading indicia of the plurality of proceduresfrom a second memory device.
 10. The memory device of claim 1 whereinthe device driver provides data to a printer in accordance with theplurality of settings.
 11. The memory device of claim 1 wherein thedevice driver provides data to an application program from a scanner inaccordance with the plurality of settings.
 12. A memory device havingindicia of a method for responding to user input provided to a devicedriver, the device driver having settings comprising a plurality ofvalues, the method comprising: in response to user input, establishing,for a first setting having a first value, a second value for the firstsetting, the second value replacing the first value, the second valuebeing a member of the plurality of values; and after the step ofestablishing: storing in a first list an indicia of the first setting;performing in turn each procedure of a plurality of procedures, eachprocedure comprising indicia of a setting to be tested, each procedurecomprising: proceeding with performance of the respective procedure uponsuccessful comparison of contents of the first list and the respectiveindicia of a setting to be tested; establishing, for a respective secondsetting having a third value, a fourth value for the second setting, thefourth value replacing the third value, the fourth value being a memberof the plurality of values; and storing in a second list an indicia ofthe respective second setting; and in response to determining that thesecond list is not empty: replacing the contents of the first list withthe contents of the second list; clearing the second list; and repeatingthe step of performing in turn each procedure.
 13. A memory devicecomprising indicia of a method for maintaining consistency of aplurality of settings for a peripheral device, the method comprising:modifying at least one setting of the plurality of settings in responseto user input; after the step of modifying, validating the plurality ofsettings by performing a plurality of checks, each check comprisingmodifying a respective setting of the plurality of settings in responseto determining that inconsistency is present among the plurality ofsettings; and repeating the step of validating, in response todetermining that any check determined inconsistency was present.
 14. Thememory device of claim 13 wherein: each check further sets a flag inresponse to determining that inconsistency is present; the methodfurther comprises resetting the flag prior to each performance of thestep of validating; and the step of repeating comprises repeating inresponse to the flag being set.
 15. The memory device of claim 13wherein the method further comprises reading indicia of the plurality ofchecks from a second memory device.
 16. The memory device of claim 13wherein a check of the plurality further comprises providing a messageto the user in response to determining that inconsistency is presentamong the plurality of settings.
 17. The memory device of claim 13wherein the method further comprises: recording a copy of the pluralityof settings; and after the step of recording, reinstating, in responseto user input, the plurality of settings in accordance with the copy.18. The memory device of claim 13 wherein the method further comprises:making a copy of the plurality of settings; making each respectivemodification to the copy; and in response to user input, discarding thecopy.
 19. The memory device of claim 13 wherein the peripheral devicecomprises a printer that receives data in accordance with the pluralityof settings.
 20. The memory device of claim 13 wherein the peripheraldevice comprises a scanner that provides data in accordance with theplurality of settings.